Thoughts from the Wet Coast
The musings of an ASP.NET Developer from Canada's We(s)t Coast

This blog was originally posted on the DNN Community blog

DNN 8 will support creating modules using a SPA (Single Page Application) model using HTML 5, JavaScript and ASP.NET Web API based web services.  In a previous blog in this series I showed how you can set up your environment to create SPA modules. This model development style has been available ever since we added support for ASP.NET Web API, but in DNN 8 we have added support for html files to be module controls.  This means that we no longer require some form of code-behind file.  So how do we do things like registering JavaScript files that we used to do in those code behind files.  In this blog I describe how we have extended DNNs token support to provide these abilities.  As before the source code for my examples is available on Github at https://github.com/cnurse/DnnConnect.Demo.

This blog was originally posted on the DNN Community blog

DNN 8 will support creating modules using ASP.NET MVC version 5.1 or later.  In previous blogs in this series I showed how you can set up your environment to create MVC modules and I created my first MVC Action/View. In this blog I will describe the support we have included for localizing text in MVC Controllers and MVC Views.  As before the source code for my examples is available on Github at https://github.com/cnurse/DnnConnect.Demo.

This blog was originally posted on the DNN Community blog

In addition to ASP.NET MVC modules, DNN 8 will support SPA (Single Page Application) modules, developed purely with HTML JavaScript and Css, together with ASP.NET Web API based Web Services on the Web Server.  DNN currently supports this module type – to a degree - but the HTML is required to be in the WebForms User Control.  A number of the newer modules have been built this way, for example the Core Messaging module and Membership modules found in the User Profile are built in this way.

This blog was originally posted on the DNN Community blog

In my previous blog I reviewed the Development Environment I will be using for my blog series on Module Development in DNN 8.  As a reminder you can find all the sample code on Github at https://github.com/cnurse/DnnConnect.Demo. In this blog we will create our first  MVC Action and View.

This blog was originally posted on the DNN Community blog

A new CTP for DNN 8 was released this week.  This CTP contains updated support for building modules using the ASP.NET MVC Framework as well as new support for building HTML 5 based modules.  This adds to the existing support for building modules with ASP.NET WebForms (User Controls) and Razor scripts. 

A couple of years ago I started a series on DotNetNuke Module Development but I didn’t get very far. Recently, I have been working on a new DNN Module Development video training course for Pluralsight and I have decided to use that module development course as a template to restart this series on how I think about DNN Module Development.   Hopefully this time I will be able to provide you with some best practices on DNN Module Development.

A Happy New Year to all readers of my Blog.  I hope 2013 was a good year for you and that 2014 will be prosperous for you and yours.

Here on the Wet Coast,  one of my New Year’s resolutions has been to be more regular in my blogging activity, and I have already made some plans in that regard.

In the first post in this series I pointed out that DotNetNuke places few requirements on module developers, and this is often daunting to new developers – “where do I start?” being a common refrain.

So where do you start?

Before we actually start to build our first module lets look at what constitutes a module.  In the default DotNetNuke skin/template that is used when installing DotNetNuke there are a number of examples of Text/HTML modules.

DotNetNuke has a rich eco-system of Modules, both Open Source and Commercial.  In many ways this is our biggest strength as a CMS platform.  No matter what you want to do with your site – there is often a module that already does it.

In my opinion this is due to the flexibility provided by the core DotNetNuke Framework.  Many other platforms are very prescriptive – as an extension developer you have to follow a fixed shopping list of rules – there is invariably only one way to create an extension, which may not work for what you want to do.